Using the EndpointSecurity (ES) API, we can subscribe to ES_EVENT_TYPE_AUTH_* events, and in the ES handler, allow or deny them. If I allow such an event in the ES handler, does this decision override the default handling of this event that would have otherwise denied this request? My guess is no, but want to confirm. Examples: Target app is runtime-hardened. Another app tries to get the task-port by doing task_for_pid() on the target app. This should result in ES_EVENT_TYPE_AUTH_GET_TASK event, event-handler allows it. A file is readable only by root, and a non-root process attempts to read it. This should result in ES_EVENT_TYPE_AUTH_OPEN event sent to the ES handler. Handler allows this to proceed. An executable is marked to be launched only by root (the file is owned by root, and the 'x' bit is set only for owner), and a non-root process attempts to launch it. This should result in ES_EVENT_TYPE_AUTH_EXEC event, event-handler allows it.

We have a sandboxed extension that we include as part of our app bundle. In some workflows, the extension launches the "main" user-facing app. In Big Sur Update 6, once the extension has launched the app, and user double-clicks a file that our app is the default-handler for, the passed in file-path in our delegate's application:openFile: method is incorrect, leading to failure in opening the file. E.g., if the actual file-path is ~/Desktop/foo.bar, the passed-in path is ~/Library/Containers/<extensionBundleId>/Data/Desktop/foo.bar This bug seems closely related to the fact that the HOME env-var in the launched app is similarly messed up. Instead of $HOME being mapped to "/Users/<userName>", it's pointing to "/Users/<userName>/Library/Containers/<extensionBundleId>/Data". i.e., it looks to be inherited from the launching process (extension). FWIW, I tried both -[NSWorkspace launchApplicationAtURL:...] and LSOpenFromURLSpec() APIs to launch the app, both resulting in the same behavior. This is clearly incorrect behavior; will this be patched in an upcoming update? Thanks